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Foreword 

This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). 

The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or 
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. 

The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under 
http://webapp.etsi.org/kev/quervform.asp . 
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Foreword 



rd , 



This Technical Specification (TS) has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



This TS defines the service requirements from users' and operators' perspective for the support of IP multimedia 
applications. 

IP multimedia applications are supported by IP multimedia sessions in the IM CN Subsystem. IP multimedia sessions 
use IP connectivity bearers (e.g. GPRS as a bearer). Examples of IP multimedia applications include speech 
communication, real time multimedia applications, shared online whiteboards etc. 

This TS, in general, does not standardise usage of IP multimedia applications, but instead identifies the requirements to 
enable their support. 

In order to align IP multimedia applications wherever possible with non-3GPP IP applications, the general approach is 
to adopt non-3GPP IP based solutions. 

The existing legacy tele- and supplementary services shall not be re-standardised as IP multimedia applications, and 
multimedia equivalent applications may be created with toolkits. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

2.1 Normative references 

[I] 3GPP TS 22.003: " CS Teleservices supported by a PLMN". 
[2] Void 

[3] Void 

[4] Void 

[5] 3GPP TS 22.101: "Service principles". 

[6] Void 

[7] 3GPP TS 22.121: "3'^'^ Generation Partnership Project; Technical Specification Group Services and 

System Aspects; The Virtual Home Environment" 

[8] Void 

[9] RFC 3261: "SIP: Session Initiation Protocol" 

[10] 3GPP TS 22.078: '; Customised Applications for Mobile network Enhanced Logic (CAMEL); 

Service definition - Stage 1 ' 

[II] 3GPP TS 22.057: '; Mobile Execution Environment (MExE); Service description. Stage 1' 
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[12] 3GPP TS 22.038: "3"^ Generation Partnership Project; Technical Specification Group Services and 

System Aspects; USIM/SIM Application Toolkit (US AT/SAT); Service description; Stage 1" 

[13] 3GPP TS 22.127: "3"* Generation Partnership Project; Technical Specification Group Services and 

System Aspects; Stage 1 Service Requirement for the Open Service Access (OSA) 

[14] 3GPP TR 2 1 .905 : 'Vocabulary for 3GPP specifications' 

[15] RFC2806: 'URLs for telephone calls' 

3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of this TS the following definitions apply: 

IM CN subsystem: (IP Multimedia CN subsystem) comprises of all CN elements for the provision of IP multimedia 
applications over IP multimedia sessions 

IP multimedia application: an application that handles one or more media simultaneously such as speech, audio, video 
and data (e.g. chat text, shared whiteboard) in a synchronised way from the user's point of view. A multimedia 
application may involve multiple parties, multiple connections, and the addition or deletion of resources within a single 
IP multimedia session. A user may invoke concurrent IP multimedia applications in an IP multimedia session. 

IP multimedia service: an IP multimedia service is the user experience provided by one or more IP multimedia 
applications. 

IP multimedia session: an IP multimedia session is a set of multimedia senders and receivers and the data streams 
flowing from senders to receivers. IP multimedia sessions are supported by the IP multimedia CN Subsystem and are 
enabled by IP connectivity bearers (e.g. GPRS as a bearer). A user may invoke concurrent IP multimedia sessions. 

3.2 Abbreviations 

For the purposes of this TS the following abbreviations apply; 
API Application Programming Interface 

CAMEL Customised Application for Mobile Enhanced Logic 

CN Core Network 

CS Circuit Switched 

GPRS General Packet Radio Service 

IM IP Multimedia 

IP Internet Protocol 

MExE Mobile Execution Environment 

OSA Open Service Access 

OA&M Operations, Administration and Maintenance 

QoS Quality of Service 

SAT SIM Application Toolkit 

SIP Session Initiation Protocol 

UE User Equipment 

VHE Virtual Home Environment 

WWW World Wide Web 



4 Introduction 

IP has opened up a whole range of communication applications, which may allow operators to develop totally new 
value added applications as well as to enhance their existing solutions. The open architecture and platforms supported 
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by IP and operating systems may lead to applications and new opportunities that are more difficult to replicate using a 
standard switched centralised solution. 

A complete solution for the support of IP multimedia applications (including voice communications) shall be available. 
The solution consists of terminals, GERAN or UTRAN radio access networks and GPRS evolved core network. One of 
the main objectives for 3GPP specifications is to ensure that the availability and behaviour of these IP applications 
when used via the 3GPP mobile access is at least as good as when used via other mobile access types. 



High level requirements 



Support for IP multimedia sessions shall be provided in a flexible manner to allow operators to differentiate their 
services in the market place as well customise them to meet specific user needs. This shall be provided by the use of 
service capabilities in both networks and terminals, for the creation and support of IP multimedia applications. 

The following high level requirements shall be supported for IP multimedia applications:- 

Negotiable QoS for IP multimedia sessions both at the time of a session establishment as well as during the 
session by the operator and the user 

Negotiable QoS for individual media components in an IP multimedia session both at the time of establishing a 
media component as well as when the media component is active by the operator and the user 

End to end QoS for voice at least as good as that achieved by the circuit-switched (e.g. AMR codec based) 
wireless systems shall be enabled 

Support of roaming, negotiation between operators for QoS and for Service Capabilities is required. Such 
negotiation should be automated rather than manual, e.g., when another operator adds new service capabilities. 

Possibility for a network operator to implement IP Policy Control for IP multimedia applications. 

IP multimedia sessions shall be able to support a variety of different media types (e.g. voice and video). A set of 
media types shall be identified to ensure interoperability (e.g. default codec selection and header compression). 

Within each IP multimedia session, one or more IP multimedia applications shall be supported 

The possibility for IP multimedia applications to be provided without a reduction in privacy, security, or 
authentication compared to corresponding GPRS and circuit switched services. 

Support for interworking with circuit switched networks,. 

Note: ITU-T specifications required for interworking between IMS and Circuit Switched (e.g. PSTN, ISDN) 
network signalling are not yet available and are expected to be part of Release 6. However this does not 
preclude the use of proprietary solutions in conjunction with Release 5.- Support for interworking with 
Internet. 

Note: 3GPP release 5 does not include additional functionality specified for Internet interworking. 

Roaming shall be supported enabling users to access IP multimedia services. - 

- It shall be possible to support session-related internet applications that have been developed outside the 3GPP 
community. 

It shall be possible to limit the view of an operator"s network topology to authorised entities. 

In R5 the ISIM application shall require the presence of a USIM application on the same UICC. This shall not 
preclude the possibility in later releases of having an ISIM in a UICC that does not contain a USIM. 



6 Standardised service capability approach 

IP multimedia applications shall, as a principle, not be standardised, allowing operator specific variations. It shall be 
possible to enable rapid service creation and deployment using service capabilities. 
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It is important that commercially available IP multimedia applications are supported. In general compatibility shall be 
with these IP multimedia applications instead of building 3GPP-specific solutions. 

The following options shall be available in the 3GPP standards to enable service delivery: 

an architectural framework shall be created that enables maximum flexibility in the end user device and network 
servers, similar in concept to that used in the Internet. 

This framework shall enable an operator to efficiently deploy IP multimedia applications in a network-agnostic 
manner without having to wait for these applications or additional enabling technology, to be standardised in 
3GPP. 

service capabilities (enhanced to control IP multimedia applications), which will allow IP multimedia 
applications to be deployed in a vendor independent manner 

CAMEL [10] and OSA [13], shall be improved to support IP multimedia applications, e.g. additions to APIs, 
service capability features, service capability servers, user profile etc. 

Note: Enhancements to MExE [11] and SAT [12] may be considered for future releases. 

mechanisms which allow the network or the application to understand the limitations of the mobile and thereby 
take appropriate actions. 

Note: There is a concern that with a large variety of toolkits to create applications, service interworking between 
terminals and networks may be compromised and needs to be addressed. 



User service requirements 



IP multimedia sessions provide the ability for users to invoke IP multimedia applications to send and receive (where 
applicable) voice and data communications, even when roaming. 

It shall be possible to support voice communications between IMS users and users of circuit switched networks (see 
section 5). The IM CN subsystem does not necessarily have to support all services offered by the circuit switched 
network. 

7.1 Identifying IP multimedia application subscriptions 

There is no requirement to support standardised subscription mechanisms for IP multimedia applications. 

IP multimedia applications may require to be provisioned and configured by users and operators. Since the source and 
variety of IP multimedia applications are not standardised, the specific feature codes to provision, enable and configure 
IP multimedia applications cannot be standardised either. Thus there are no requirements on the network capabilities to 
support provisioning and configuration for specific IP multimedia applications. 

Note: The standardised service capabilities, personalised Internet web pages and evolving IP mechanisms may be 
used to allow user (self) provisioning, configuration and enabling of IP multimedia applications. 

7.2 Access to the IM CN subsystem 
7.2.1 Access control 

The IM CN subsystem shall be able to verify at any time that the user is entitled to use the resources of the IM CN 
subsystem. 



7.3 Capability negotiation 



The IP multimedia applications shall be able to negotiate their capabilities to identify and select the available media 
components, QoS etc. of IP multimedia sessions. It shall be possible for the capability negotiation to take place on 
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invocation, acceptance and during an IP multimedia session (e.g. following a change in UE capabilities, change in 
media types etc.). Capability negotiation may be initiated by the user, operator or an application on behalf of them. 

In order to support the user's preferences for IP multimedia applications, the capability negotiation shall take into 
account the information in the user profile whenever applicable. 

7.4 Redirecting of IP IVIultimedia sessions 

It shall be possible for the user or the network to identify an alternative destination for an IP multimedia session. 
Redirection to alternative destinations may be initiated by the sending party, receiving party or the network on their 
behalf. It shall be possible for redirection to be initiated at various stages of an IP Multimedia session. For example: 

Prior to the set up of an IP Multimedia session 

During the intial request for an IP Multimedia session 

During the establishment of an IP Multimedia session 

While the IP Multimedia session is ongoing 

Redirection can be applied for all Multimedia sessions unconditionally or it can be caused by any of a set list of events 
or conditions. Typical causes could be: 

Identity of the caller 

Location or presence of the calling or called party 

If the called party is already in a session 

If the called party is unreachable or unavailable in some other way 

If the called party does not respond 

After a specified alerting interval 

There are other causes that could be applied that do not require standardisation (e.g. time of day). 

7.5 Invoking an IP multimedia session 

The user shall be able to invoke one or more IP multimedia sessions. The user shall also be able to activate concurrent 
IP multimedia applications within each IP multimedia session. 

7.5.1 Identification of entities 

Both telecom and internet numbering and addressing schemes shall be supported as public identities. IP multimedia 
communication establishment (both mobile originating and terminating) depending on originator shall be able to be 
based on E.164/TEL URL (e.g. tel:+4412345678) [15]or SIP URL (sip:my.name@company.org) [9]. It shall be 
possible to assign several public identities for one subscription. 

Public identities shall be administered by the network operator and shall not be changeable by the user. 

It shall be possible for the network operator to guarantee the authenticity of a public identity presented for an incoming 
call to a user where the call is wholly within that operator"s network (i.e. originating and terminating parties are 
subscribers to, and resident in, a single PLMN). This is equivalent to the situation for CLIP with today"s telephony 
networks. 

It shall be possible for the network operator to use 

- the same E. 164 number for IP multimedia sessions and CS speech telephony (TSll) [1] 

- a different E.164 number if desired for IP multimedia sessions 
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This allows customers who originally had only an El 64 MSISDN to retain the same number for receiving 
communications in the IM domain and also in the CS domain when outside IM coverage. 

7.5.2 Negotiation at IM session invocation 

It shall be possible for the capability negotiation to take place at the time of the IP multimedia session invocation. Refer 
to subclause 7.3 for further details on capability negotiation on IP multimedia session invocation. 

7.5.3 Void 



7.6 Handling of an incoming session (by the terminating entity) 

7.6.1 Presentation of session originator identity 

It shall be possible to present the identity of the session originator (see 7.5.1) subject to it not being suppressed by the 
session originator. 

7.6.2 Negotiation of an incoming session 

Interaction with the user profile shall be supported, and additionally direct interaction with the user may be required. 
Refer to subclause 7.3 for further details on capability negotiation on an incoming IP multimedia session. 

7.6.3 Accepting or rejecting an incoming session 

It shall be possible for the user to either accept or reject an incoming IP multimedia session. Further, it shall also be 
possible for the user to accept only a subset of the offered media, not have any of the media offered to him at all etc. 

7.7 Handling of an ongoing session 

7.7.1 User modification of media in an ongoing session 

The user shall be able to negotiate the addition or deletion of media components of IP multimedia applications during 
an IP multimedia session. Refer to subclause 7.3 for further details on capability negotiation during an IP multimedia 
session. 

7.7.2 Suspending and resuming of an ongoing session 

It shall be possible for the user to suspend an IP multimedia session, and resume that IP multimedia session at a later 
time. 

7.7.3 Presentation of identity of connected-to party of a session 

It shall be possible to present to the originator of a session the identity of the party to which she is connected (see 7.5. 1). 
However, the connected-to party shall be able to request that her identity is not revealed to the originator of the session. 

7.8 Ending a session 

The user shall be able to end an IP multimedia session at any time during the session. 

7.9 Void 



£75/ 



3GPP TS 22.228 version 5.7.0 Release 5 1 1 ETSI TS 1 22 228 V5.7.0 (2006-03) 

Annex A (informative): 

Example IP multimedia application scenarios 

The following example scenarios describe the personalised handling of individual media in multimedia applications 
(note that this list is neither complete nor exhaustive):- 

1 . The user is in a voice communication, and receives an incoming IP video communication. The user decides not to 
accept the communication, but diverts the incoming video to a messaging system. Further, the user is given an 
indication that there is a video message in his mail box 

2. The user is in a voice communication, and receives an incoming video communication. The user decides to accept 
the communication but wishes to switch between the two communications. 

3. The user is idle in a network and not involved in a communication. The user modifies his user profile to divert all 
voice communications other than those from high priority, pre-identified callers (e.g. his boss). In this scenario all 
emails and text messages continue to be received regardless of the sender. 

4. On receiving a communication, the calling party's identity is displayed (if not restricted) and user shall be able to 
decide whether to accept the communication, or divert to a messaging system. The user shall be able to request 
media handling of the communication (e.g. media splitting to different destinations, media conversion). 

5. The user is busy in a communication when receiving an incoming communication, but responds to the originating 
party that he will respond later. The user may request that the originating party's details (if not restricted) are stored 
with a reminder in user's profile. 

6. Hi-fi sound (nuances, character of voice) 
Person(s) : Marketing Manager, Rita 

Situation : She is at a launch party for some customers in London. In the break she listens to her messages and one 
from another customer in Tokyo gets her attention. He just wants her to call, but doesn"t say if it is urgent or not. 
Solution : Due to the excellent sound quality of the terminals involved and the messaging system, she picks up the 
faint irritation in his voice and decides to call him immediately. It was urgent and she could remedy the situation 
easily by emailing the information from her built in PDA storage. The customer was relieved as he was just going 
in to a very important meeting. 

Benefit(s) : Good sound quality gives more information to base judgements on, i.e. emulates real life meetings 
better. 

7. Stereo sound (nuances, character of voice plus positions, sound-scapes) 
Person(s) : Purchase Officer, Gustavo 

Situation : Participates in a conference to discuss purchase of a new kind of steel for the factory in Rio. As he is on 
the road he calls from his hotel room in Sydney. The conference is in the head office in Rio. The local department 
has invited the two final contenders to have them argue their cases. The two companies are positioned at the 
different ends of the table. One of the groups is presenting and mentions something about deliveries. A side remark 
is barely audible, 'we can"t deliver that quality and that quantity this year !' Who gave this remark? 
Solution : The excellent sound quality together with the stereoscopic sound gives Gustavo the information he 
needed. It was the other group that gave the remark. The decision was made for him at that point. He gave the order 
to the presenting group right after they finished a very good presentation that told him everything he wanted to 
hear. The setup at the head office was done with two synchronized UEs at each end of the table. 
Benefit(s) : Stereoscopic sound gives even more information than just hi-fi sound to base judgements on, i.e. 
emulates real life meetings better. 

8. Conference/chat with "private rooms" 

Person(s) : A project team at an IT company: Rick, Diana, Ted, Sven and Liu 

They are based in different cities. 

Situation : The project team has one of their weekly reporting meetings using their mobile communicators. In the 

middle of the meeting. Rick and Diana get lost in a lengthy arguing on some detailed design matters that bores the 

rest of the team. Ted, the moderator, finds that it is nevertheless necessary to give Rick and Diana some minutes to 

finish their discussion, so he decides to not interrupt them. At the same time Sven remembers that he need to 

remind Liu to send a report to him on the latest findings from her research work. 

Solution : The team use a conference/chat service with the new facility "private rooms". This allows Sven to direct a 

few words in privacy to Liu. Sven activates easily this feature by the GUI of his communicator. Liu is immediately 

notified by the GUI of her communicator that Sven is now talking privately with her (this is necessary to avoid 
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embarrassing misunderstandings that could occur if Liu would answer Sven in the "common room" instead of in 

the new "private room" that Sven has created). 

Since the voices of all conference members are synthetically mapped in a stereophonic projection, Liu is able to 

hear what Sven is saying, even though he speaks simultaneously with the other team members (the communicator 

will not automatically adjust the sound volume of the "common room", since it cannot know if Liu is more 

interested in Sven's comments or in continuing to listen to the other team members). 

Benefit(s) : This service emulates virtual presence in a conference room in the best possible way without adding 

more visionary technologies like holographic projections, etc. The synthetic stereophonic sound projection provides 

good possibilities for a conference member to discriminate unwanted voices even if the meeting situation is 

informal and spontaneous and everyone are talking at the same time. The flexible possibilities to create one or more 

"private rooms" make it easy to make private comments to selected colleagues. The easy-to-use and fast responding 

GUI makes the needed end-user effort to create a new "room" so low, that it feels natural to use the function even 

for exchanging just a few quick words. 

Alternative use : Exchange the IT project team with a gang of teenagers that are planning what to do in the 

weekend. The service works perfectly well also in that scenario and provides the same benefits. 

Additional features : Easy GUI controlled addition of new participants (can be initiated by any of the participants), 

including addressing, notification/invitation, etc. (cf. "outgoing call" in PSTN). GUI notification of new incoming 

session invitations (cf. "incoming call" in PSTN) and possibility to choose action as desired (incorporate the 

"calling party" in the existing conference session, creating a new separate session, rejecting the invitation, diverting 

it to a messaging system, etc.) Whiteboarding and/or application sharing. 

9. Multiplayer mobile gaming with voice channel 

Person(s) : Joe (age 15), Blenda (age 14), Fredric (age 15) and all their "cyber friends" in the Shoot-n-Shout v. 14.0 

community 

Situation : In the legendary multiplayer game Shoot-n-Shout v. 14.0 the most popular game mode is a team 

competition. The idea is simply to shoot down the members of the concurring teams. There are always a lot of 

active game sessions in CyberSpace. At a web/WAP service operated by the game application provider, interested 

potential players can choose a game session and also find other gamers to form a team with. There is a text chat 

service where potential team-mates can learn to know each other. 

Joe, Blenda and Fredric meet on the web/WAP chat and decide to form a team to take up the fight in one of the 

Shoot-n-Shout sessions. They are preparing a game strategy in advance through the text chat service, but when they 

have started the battle it takes too long time to type text, so they the will need another way to communicate with 

each other. 

Solution : The game application provider makes use of a conference/chat service with "private rooms" in order to 

provide a multi-player voice service to the players of Shoot-n-Shout. When a game starts there is one "common 

room" where all players can talk (or rather shout) to each other and one "private room" for each team. Players in a 

team can also dynamically create more "private rooms" if they only like to talk to one (or a few) of their friends. 

(See the conference/chat scenario for details.) 

The volume (and stereophonic position) of the players voices when they are using the "common room" is controlled 

so that it matches the virtual surroundings in the game environment. As an example, players that are behind a wall 

will only be heard as a vague whisper in the distance. 

Benefit(s) : A voice channel will enhance the gaming experience for several popular network games. 

10. Application sharing with voice commentary 

Person(s) : Marketing Manager, Rita and Media expert, Jones 

Situation : The launch of a new campaign for some customers in London. Last minute feedback is that one of the 

customers is expecting the latest gadget to be included, even if its only a prototype. Rita knows it"s not included in 

the presentation and she has no information with her. 

Solution : Rita calls Jones, the media guru they employed for design of their important presentations. He has the 

information and some pictorials. He sends them over into Rita"s PowerPoint application and they edit the new slide 

together as they discuss the textual information to be included. 

Benefit(s) : The process is extremely interactive and the session takes only 5 minutes thanks to the broadband 

connection and the fact that they don"t need to Ping-Pong the pictures and the text back and forth. (Emphasize 

mobile or fixed access as required). The customer is happy and a Letter of Intent is signed. 

Comments : By adding voice and pictures in an interactive session we achieve both effectiveness and interaction, 

two desired components. 

1 1 . The Real Virtual Theatre and Foyer Chat room - Fixed Network example 
Person(s) : Theatre going 'cultural' group with one member (Bob) in a hospital bed. 

Situation : The group is watching the play and are utterly fascinated by the first act. When they come out into the 
foyer in the break they remember Bob. They really want to share this first act with him since they know 
Shakespeare"s Midsummer Night"s Dream is his favorite. 
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Solution : Bob uses the theatre"s online streaming service via the hospital network. (At only half the price of a 
theatre ticket!). The play displays in color and stereo surround sound on his bedside TV set. In the break his friends 
call him up from the theatre chat room. The chat room is equipped with 3D sound pick up and local display screens 
with streaming facilities. They set up the streaming from one of the screens to be synchronized with Bob"s bedside 
equipment. Their voices are also mixed into the sound streams as they talk. Bob now gets both the playbacks from 
the first act and his friends" voices in 3D surround sound. Bob"s voice is projected close to the screen as if he was 
standing leaning on the bench right there. His voice is very clear and full of emotions as he speaks to the various 
playbacks. Both parties can control the playbacks and watch their own selection in a second window on the screen. 
Benefit(s) : Bob can pick up every nuance in the lively discussion, including the whispered comments from Greta in 
the back. The group is almost feeling Bob"s presence because of the emotional clarity and distinct position of his 
voice. As both parties have control and visibility of the streaming sessions, it is very effective and very interactive. 
Comments : Experiential services are sought after. This one can be a bit exclusive because of the equipment 
requirements, but the uses are many. 

12. Mobile synchronized MM container 

Person(s) : The married couple Bill and Christine and their daughter Linda 

Situation : Bill is on a business travel to Spain. He calls his wife Christine every night using his MMM terminal. 

Often Christine is answering at home using her Screenphone, but this particular evening Christine has arranged a 

baby-sitter for their children so she could go to a restaurant with some friend. When Bill is calling, she is sitting on 

the commuter train on her way home. Bill often show some pictures during his calls (both live pictures showing the 

environment where he is at the moment and pictures that he has been taking during the day with his separate digital 

camera). 

Today, their talk starts off as a common voice conversation. After a while Bill likes to show Christine the lovely 

sunset view that he can see from his hotel room, so he make some snapshots with the built-in camera of his 

terminal and sends them in real-time mode to Christine. Christine likes to show one of them to their little daughter 

Linda when she comes home. 

Solution: With a quick gesture on the touchscreen of Christine" s MMM terminal, she instantly moves the selected 

picture from the real-time session window to the 'multimedia container' icon. All the contents of the 'container' is 

automatically mirrored between the MMM terminal and her home server. In this way, Christine can easily pick up 

the picture from her Screenphone at home. If Linda is at sleep when Christine comes home, she can wait until 

tomorrow. 

Benefit(s) : The 'multimedia container' can be used for every type of MM content that one likes to have available 

both at home and at another location. This 'container paradigm' is very intuitive and stimulates the use of images, 

video clips etc. for a multitude of purposes. The 'container' can be used both for transferring content from the 

MMM terminal to the home server (as in this scenario) and in the opposite direction. 
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